The communications industry is rapidly changing to adjust to emerging technologies and ever increasing customer demand. This customer demand for new applications and increased performance of existing applications is driving communications network and system providers to employ networks and systems having greater speed and capacity (e.g., greater bandwidth). In trying to achieve these goals, a common approach taken by many communications providers is to use packet switching technology. Increasingly, public and private communications networks are being built and expanded using various packet technologies, such as Internet Protocol (IP).
A network device, such as a switch or router, typically receives, processes, and forwards or discards a packet based on one or more criteria, including the type of protocol used by the packet, addresses of the packet (e.g., source, destination, group), and type or quality of service requested. Additionally, one or more security operations are typically performed on each packet. But before these operations can be performed, a packet classification operation must typically be performed on the packet.
Packet classification as required for, inter alia, access control lists (ACLs) and forwarding decisions, is a demanding part of switch and router design. The packet classification of a received packet is increasingly becoming more difficult due to ever increasing packet rates and number of packet classifications. For example, ACLs require matching packets on a subset of fields of the packet flow label, with the semantics of a sequential search through the ACL rules. IP forwarding requires a longest prefix match.
Known approaches of packet classification include using custom application-specific integrated circuits (ASICs), custom circuitry, software or firmware controlled processors, binary and ternary content-addressable memories (CAMs). The use of programmable software or firmware have advantages as they provide some level of flexibility, which becomes especially important as new protocols and services are added to existing network. Customer typically desire to use their existing hardware (e.g., routers, switches, etc.) to support these new protocols and services. However, known software and firmware implementations are relatively slow, and typically place a performance bound which may be incompatible with new requirements. Various applications that use packet classification, such as Security Access Control, Quality of Service, etc., typically need to perform many matches on source and destination port numbers, protocol and/or other header fields, etc. in order to identify a corresponding netflow.
In a known prior system, one or more fields are extracted from a received packet. These one or more extracted fields typically include source and destination addresses, port numbers, and possibly other fields, typically included in the header or flow label of a packet. These extracted fields are provided in their native format, possibly along with other data, to a CAM, which performs a lookup operation in performing the packet classification. Because CAMs are expensive, especially in terms of space and power consumption and are limited in the width of an input lookup word, one known system preprocesses, via one or more logical functions or operations, certain information contained in a packet to generate a vector that is used as part of a lookup word. This vector reduces the number of bits that would be required if the entire native information was included in the lookup word. However, such known preprocessing only operates on the information contained in a received packet and not from any other source.
Programming an ACL can be a complex and/or redundant task. Typically, each network or possibly even host system requires a separate series of ACL entries. One known system reduces the overall numbers of ACLs by assigning virtual local area network (VLAN) identifiers to entities (e.g., networks, hosts, and router interfaces). A common ACL can then be shared by multiple entities by mapping their VLAN identifiers to a shared VLAN label, with this shared VLAN label being used to identify the common ACL or entries thereof.
However, in many situations, ACLs used on different interfaces are not the same as, for example, they might have different security requirements. Also, different interfaces may belong to different subnets and use different IP addresses; and thus, for example, separate ACLs entries must be used to verify that the source address of a packet sent from an interface matches the address of the interface. This creates a difficulty especially in the case of a dial-in public network, where the connecting computer and user varies, and the only mechanism currently available to ensure that a packet sent from the connected computer is authorized (e.g., its source address corresponds to the one assigned to it by the dial-in system), is to use a separate ACL for each interface, which can be quite tenuous and expensive as each ACL must be programmed separately.
For example, assume an ACL is needed for a VLAN to disallow ten specific users from accessing ten specific servers and allows all other traffic from these users, and no additional restrictions are being placed on this VLAN. In a network where IP addresses are dynamically assigned, it is impossible to implement this using a classical ACL model because these IP addresses for these users are not known in advance. Even in the case where these users always get their same IP address, the ACL on this VLAN will have one hundred ACL entries (i.e., the cross-product of ten users and ten servers). A portion of an example of this configuration is shown in ACL 100 in FIG. 1. Should more servers and/or users need to be specified, the number of entries grows dramatically.
Dynamic Host Configuration Protocol (DHCP) is a commonly used mechanism to dynamically assign an IP address to a host. Typically, a host broadcasts a message which is responded to by a DHCP server which provides the new address for the requesting host.
Another service that is currently used in a network is user authentication using an 802.1x port-based authentication protocol. Typically, when a host connects to a physical port on the switch/router, it is prompted for a username. The switch/router passes the username to an authentication server, which sends a challenge to which is responded in order to authenticate the host (essentially the user on the host). Along with authenticating the user to the switch/router, the authentication server can also pass some more information about the user. The traffic of an unauthenticated host/user is typically blocked until it is authenticated. The 802.1x port-based authentication protocol has been implemented on Windows XP, Linux, and various other operating systems and is slated to become standard security feature in most enterprises.
It is desired that security and other features be provided to reflect the dynamic nature of network address assignment, as well as host/user authentication.